1. Field of the Invention
The present invention relates generally to wireless communications networks and related systems and devices. More particularly, exemplary embodiments of the invention concern systems and methods for using distributed network elements to implement monitoring and data collection concerning selected network parameters.
2. Related Technology
As a result of advances in technology and enormous increases in the number of wireless device users, the size and complexity of wireless communications networks has greatly increased. An inevitable consequence of such increases in size and complexity has been a relative increase in operational and performance problems associated with communications networks. Reliability issues, such as dropped calls, lack of coverage, and poor audio quality are impeding the acceptance of wireless technology by end users. These and other quality issues have prevented many end users from relying upon wireless voice and data services as their primary means of communication. As new services are introduced that use even more complex technology, exercise different usage modalities, and place additional demands on networks already laden with problems, network performance will deteriorate further. Quality of service has a direct impact on customer churn, a tough and costly problem that reduces profitability. Therefore, improving quality of service is a top priority for service providers.
Network monitoring solutions are well known in the art and widely employed by service providers, however, currently available solutions can only monitor and diagnose subsets of the overall telecommunications system and therefore do not provide the holistic view of network and device performance needed to efficiently identify and resolve quality issues. Typical approaches to network monitoring include “self-monitoring” wherein a network element reports on its own status and performance and reports any errors that occur during its operation. The resulting operational metrics from a single element can sometimes be indicative of a broader, system-wide problem, but rather than providing answers, problem resolution entails guesswork and extended troubleshooting, which wastes valuable resources. Another common approach includes placing probes at various points in the network to determine if network elements are functioning according to specification. Sometimes referred to as “sniffers”, “log monitors” or “event monitors”, these monitoring systems are effective at identifying performance issues with a particular network element, but they fail to capture problems that stem from the interfaces among network elements, i.e., these solutions do not address the case where single elements are performing according to specifications, but problems occur when those elements interact with one another. This far more complex and subtle set of problems has costly consequences to network operators when services cannot be delivered to end customers.
Another monitoring approach known in the art involves pre-programmed service monitors, where specific elements perform service transactions to emulate “real-world” transaction activity; end to end performance is then monitored and the results reported. While these solutions catch systematic failures, they cannot detect intermittent or dispersed problems, subtle impairments, or device or end user specific issues. Further, they can only test anticipated usage scenarios and fail to adapt to new usages and interactions between services.
Significantly, the aforementioned solutions lack the ability to monitor network conditions and intelligently and dynamically define and generate data collection models in response to changing network conditions. Even with the employment of probes in a communications network, it is often the case that the probe provides only an indication of a problem, and actually troubleshooting the problem requires personnel to be dispatched to a physical location on the network, adding significant time and cost to problem identification and resolution. Moreover, these troubleshooting techniques do not provide a multi-faceted view of the different network layers, such as the physical layer, the applications layer, etc., and they do not correlate performance issues across these layers. As a result, numerous quality issues impacting end users go undetected or are misunderstood. Consequently, they may become crises because the performance data provided by currently available network monitoring solutions lacks the detail and timeliness needed to quickly identify, prioritize and resolve network issues.
Furthermore, currently available network monitoring solutions cannot adequately monitor and report on a particular end user's experience with network usage, therefore, service providers must rely upon the end user to report performance problems to a customer service representative. However, it is frequently the case that once reported, an end user's problem cannot be duplicated due to the difficulty of recounting the details of what s/he experienced, the timing of the occurrence, and the lack of underlying data to validate the issue. Additionally, because the service provider is unable to view network performance holistically, it likely does not understand the true scope of the reported problem and it cannot appropriately prioritize the problem for resolution. The problem, therefore, is not resolved to the reporting end user's satisfaction, creating a disincentive for the end user to diligently report problems in the future. Furthermore, an opportunity to prevent the issue from affecting others and to improve the overall quality of the network is missed.
Thus, situations frequently arise where the end user is alienated from the company providing the communications service, without the service provider even being aware of the cause or source of the end user's dissatisfaction. Moreover, because so many end user problems go unreported, it is almost impossible for service providers to obtain reliable information about the scope of a particular issue. Therefore resources are frequently spent solving issues that are well described, but only affect a small number of end users, versus problems that are poorly described but effect a much larger number of end users. As a result, a service provider with an incorrect understanding of the scope of an issue may allocate an inappropriate amount of resources toward resolution, or it may fail to recognize the value of prioritizing resolution.
Still other monitoring solutions known in the art are directed to gathering and analyzing information about the performance of wireless devices. Typically, the monitoring software will be installed on a wireless device at the time of manufacture or by downloading the software onto the device. The software then runs continuously in the background, monitoring device and application performance. When a particular event or error associated with the device occurs, the software collects the data associated with the error or event and may upload it either in real time or at a later time to a data repository for analysis. As discussed below however, such approaches are inflexible and fall well short of an adequate or effective solution.
Just as the aforementioned network monitoring solutions monitor the performance of particular elements in the network, the wireless device monitoring software contributes another set of data points concerning the performance of the wireless device, but the fundamental problem remains that while device performance information is useful, it is disconnected from the other performance data being generated elsewhere in the network, and there is no mechanism for understanding this data in the context of the performance of multiple network elements across network layers.
Furthermore, such approaches tend to emphasize the use of pre-configured data gathering software. While the software can be instructed to collect certain subsets of data, the software cannot be quickly revised or modified to accommodate rapidly emerging and changing conditions. That is, the software can only collect the data that was originally programmed to be collected and further, such data can only be collected in accordance with the conditions initially programmed. Thus, the capabilities of such software are constrained by the foresight of the programmer. Because it is simply not possible for a programmer to be able to anticipate the wide variety of usage conditions, problems and events that may occur in connection with communications network operations, this lack of flexibility is a significant limitation.
This lack of flexibility is also problematic in situations where a transient network condition occurs. In particular, because the software cannot be quickly and easily updated to respond to changing network conditions, the window of opportunity to collect data concerning a transient network condition may close before the software can be modified to target that data, thus denying network administrators and other personnel the opportunity to adequately diagnose and resolve the problem.
Finally, the flexibility of such software is further impaired by the fact that such software is either loaded on the mobile phone at the time of manufacture, or must be downloaded from a web site or service. Thus, revisions or updates to the data gathering software are somewhat cumbersome and time-consuming to obtain. Because different users may load the revised software, if at all, at different times, there is no quick and reliable way to ensure that a statistically significant number of devices are available, with the appropriate software, to gather the data needed for a particular analysis.